Most plants have gotten good at OEE. The dashboards are mature, the downtime reason codes are reasonably clean, and everyone in the daily production meeting can tell you yesterday’s availability number to a decimal point. And yet scrap rates on a lot of lines haven’t moved much in years. That’s not a coincidence — it’s because OEE and quality data usually live in separate analytical universes, even when they sit in the same MES database.
Micro-stops are the gap. A stoppage under a minute or two almost never registers as a meaningful availability hit. Roll it up into a shift total and it disappears into rounding error. But a cluster of micro-stops on a specific station, in a specific sequence, is very often the physical signature of a process drifting out of control before anyone pulls a bad part off the line. The scrap shows up minutes or hours later, gets coded as a material defect or an operator error, and the micro-stops that predicted it never get a second look because nobody built the query that connects them.
Why micro-stops get ignored in the first place
Two structural reasons. First, most OEE calculations bucket “small stops” into a single loss category by design — that’s standard practice going back to the original Nakajima framework, and it’s fine for scoring the shift. But it throws away exactly the granularity you need for root-causing anything. Second, a lot of PLC and SCADA configurations simply don’t resolve at the timescale where micro-stops live. If your historian is polling at a one-second or five-second scan rate and your MES only logs a downtime event once a stop crosses some threshold — often 60 or 90 seconds by default in commercial downtime modules — you are structurally blind to the eight-second stall on the infeed conveyor that happens forty times a shift.
That eight-second stall might be nothing. Or it might be the servo on the pick-and-place hunting for position right before it starts placing parts slightly off-center. You can’t tell the difference until you’ve got the data logged and correlated.
Step 1: Get your event resolution right at the source
Before any analysis is possible, check what your PLC and MES are actually capturing.
- Lower your micro-stop threshold. Most downtime tracking modules let you configure a minimum duration before a stop is logged as a discrete event rather than absorbed into cycle time variance. Set it low — a few seconds, not a minute — for the stations you’re targeting. You can always roll these up into “micro-stop” buckets in reporting; you can’t recover events you never captured.
- Timestamp at the PLC, not the MES ingestion layer. If your architecture logs the event when the MES polls or when an OPC UA subscription fires, you’re introducing jitter that will blur your correlation window. Push a hardware or PLC-scan timestamp through with the tag change, not a “time received” stamp.
- Tag the right fault states, not just E-stops. Servo faults, sensor blocking/jam signals, low-air-pressure interlocks, and vision-system no-reads are often wired to stop the line momentarily without ever generating a formal “downtime reason” — they just show up as a cycle time anomaly. Make sure those discrete signals are actually mapped to loggable tags, not just used internally by the PLC logic.
- Keep a rolling buffer, not just event logs. A short local buffer (station state, key process values, a few seconds pre- and post-event) gives you context around each micro-stop instead of just a start/stop timestamp. This is what turns “a stop happened” into “a stop happened while torque was trending high.”
Step 2: Bucket micro-stops by pattern, not just duration
A flat list of sub-two-minute stops is noise. Group them before you try to correlate anything:
- By station and fault code — the same interlock tripping repeatedly is a different animal than scattered one-off stops across the line.
- By frequency trend — a station that normally micro-stops twice an hour and is now stopping eight times an hour is telling you something even if each individual stop is trivial.
- By time-since-changeover or time-since-PM — micro-stops that cluster right after a changeover or that increase steadily since the last maintenance interval point at tooling wear or setup drift rather than a random fault.
- By shift and operator pattern — sometimes what looks like a process signal is actually a training or method issue. Rule that out before you chase a phantom equipment cause.
Step 3: Join the downtime stream to the quality stream
This is the actual payoff step, and it’s mostly a data engineering problem, not an analytics one. You need a common key — serial number, lot ID, or at minimum a tight time window — that lets you ask: for every scrapped or reworked unit, what micro-stop activity happened at upstream stations in the preceding window before that unit was produced?
If your MES already tracks genealogy (which most do, at least at the lot level), this join is usually straightforward in whatever reporting or historian layer you use. If you’re running unit-level traceability, you can get tighter than lot-level and actually attribute a specific defect to a specific stop event a few units earlier — which is a much stronger signal for engineering to act on than “scrap was up on Tuesday.”
Run this backward first, on a few weeks or months of existing history, before you build any real-time alerting. You’re looking for a repeatable pattern: does a burst of micro-stops on Station 4 reliably precede a rise in dimensional rejects two to five units later? If you can’t find that pattern in historical data, don’t build the alert yet — you’ll just be alarming on noise.
Step 4: Set thresholds that won’t get muted by week two
This is where most attempts at this die. Alert on every micro-stop and operators will silence the notification inside a shift. The goal is a threshold tuned to the pattern you actually found in Step 3, not a generic “more than N stops per hour” rule pulled out of the air.
- Alert on rate of change, not absolute count — a station’s baseline micro-stop frequency matters more than a fixed number.
- Require the pattern to repeat across a rolling window (say, three consecutive periods trending up) before it fires, to filter single-event noise.
- Route the alert to whoever can actually act on it in the moment — usually the line lead or a floating tech, not a report that lands in an inbox after the shift ends.
- Give the alert a specific, testable instruction, not just a flag. “Station 4 micro-stops trending up, check servo position feedback and vision alignment” gets acted on. “Anomaly detected” gets ignored.
Expect to spend a real tuning period — weeks, not a single shift — adjusting thresholds against actual scrap outcomes before the alert earns operator trust. That tuning cost is the whole reason most plants never get here on their own; it’s tedious, unglamorous work that doesn’t show up on an OEE dashboard. But it’s also the difference between reacting to a scrap lot after the fact and catching the drift while it’s still just a few seconds of hesitation on a conveyor.
What “done right” looks like
You’ll know this is working when quality holds and maintenance start referencing micro-stop trends in the same breath as defect codes — when a line lead says “Station 4’s been hunting all morning, let’s check it before we run the next lot” instead of finding out from a rejected pallet. The OEE number probably won’t move much; that was never the point. The scrap trend line will.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
